It has long been known that what is referred to here as a "system" can constitute a part of a network and includes a plurality of different mutually coacting nodes, by forming the nodes in a distributed data base for instance. In such a system, different transactions constantly take place between two or more nodes. These transactions shall be carried out in a positive and time effective manner.
So-called distributed transactions means that a transaction shall be performed between a plurality of nodes or participants. A transaction may involve any commitment that concerns a plurality of nodes. Two methods are well known in connection with distributed transactions, these methods being traditional commit in two phases and linear commit. By commit is meant that a participant has undertaken to do something and also does it.
It is also known to utilize safety copying, or back-up copying, of information in a distributed data base. Thus, a primary copy of part of a table is stored within a first node and a second copy of the same part is stored within a second node.
A primary copy with associated secondary copy is called a fragment in this document. A transaction that affects a part of a table thus also affects a fragment of a table that includes both a primary copy and a secondary copy of this part of the table. When a distributed transaction can include a plurality of different tables, or a plurality of different parts of a table, a plurality of different fragment and associated copies will also affected.
Traditional commit in two phases and linear commit are beneficial in different ways in respect of a transaction that affects a plurality of fragments. This will be described in more detail below with reference to the accompanying drawings.
However, it will be mentioned briefly at this stage that
"traditional commit in two phases" requires a large number of messages to be sent, although this can be performed partly in parallel and therewith places high requirements on processor and transmission capacity, but affords relatively short response times, whereas PA1 "linear commit" requires a smaller number of messages to be sent, although essentially serially, and therewith places less demand on available processor and transmission capacity, but gives relatively longer response times PA1 the transaction coordinator sends a message "prepare" to the first node, in other words a request for the preparation of the transaction, PA1 when the first node is able to undertake the transaction, said first node then sends the preparation request to the second node, either directly or via one or more intermediate nodes, or PA1 when the first node is unable to undertake to carry out the transaction, said first node then sends a message "unprepared" to the second node, either directly or via one or more intermediate nodes, PA1 when the second node is able to carry out the transaction, said second node then sends a message "prepared", i.e. that all affected nodes are prepared to carry out the transaction, directly to the transaction coordinator, or PA1 when the second node is unable to carry out the transaction or when the second node has received the message "unprepared", said second node then sends a message "unprepared", directly to the transaction coordinator, PA1 the transaction coordinator sends to the second node a message concerning the measures to be taken; PA1 the second node then sends to the first node the message concerning the measures to be taken, either directly or via one or more intermediate nodes; and PA1 the first node then sends a concluding message to the transaction coordinator, PA1 the transaction coordinator checks all ongoing message transmissions, PA1 the phase of the transaction that has been halted is restarted from the beginning, PA1 the messages are sent in accordance with this phase but with the crashed node excluded from the message chain, and that PA1 a node that receives a previously received message ignores the message and forwards the same. PA1 the system coordinator sends a general query to all nodes in the system asking whether any node is participating in a transaction in which the crashed node is the transaction coordinator, PA1 a new node is assigned the role of transaction coordinator, PA1 all nodes in respective fragments affected by the transaction compile a status report which is sent to the new transaction coordinator and which includes node identity, fragment identity, transaction status, and whether the node is a primary, secondary or stand-by copy in respective fragments, and that PA1 the new transaction coordinator decides on the basis of the status reports whether the transaction shall be continued or aborted.
in one and the same transaction.
It is also known to use so-called system redundancy with the intention of obtaining redundancy in a system, meaning that a parallel secondary copy of the complete system is found. A second copy is completely separate from the primary copy with regard to hardware.
Promotion of a secondary system to a primary system only takes place in the event of a total collapse of the primary system, i.e. a total crash.
So-called blocking of the system can occur should a transaction coordinator crash during a transaction. This means that the system must wait until the crashed transaction coordinator has re-started or until a secondary copy of the transaction coordinator is promoted to a primary copy and taken over the role of transaction coordinator.
It is known to create a so-called "non-blocking coordinator" in this context. One such coordinator is described in the publication "Location and Replication independent recovery in a highly available database", Svein Erik Bratsberg, Svein-Olof Hvasshovel, Oysten Torbjornsen. Telenor R&D.
In brief, this method involves the use of parallel transaction coordinators, which in turn entails very high performance costs.
Mention is also made here to the publication "D3 Dynamic Data Distribution Algorithm" by Chamberlain, published at the conference "Very Large Databases" in Vancouver, 1992, which also describes the handling of a crashing transaction coordinator during a transaction.